home *** CD-ROM | disk | FTP | other *** search
/ AMOS PD CD / amospdcd.iso / aminet / amoslist0993.lzh / AMOSLIST2 / 000065_amos-request@svcs1.digex.net_Wed Sep 1 20:41:46 1993.msg < prev    next >
Internet Message Format  |  1993-09-03  |  5KB
  1. Received: from nextsun.INS.CWRU.Edu by access.digex.net with SMTP id AA19329
  2.   (5.65c/IDA-1.4.4 for <mcox@access.digex.com>); Wed, 1 Sep 1993 20:41:43 -0400
  3. Received: from svcs1.digex.net by nextsun.INS.CWRU.Edu with SMTP (5.65b+ida+/CWRU-1.5.2-freenet-gw)
  4.     id AA20177; Wed, 1 Sep 93 20:41:25 -0400 (from amos-request@svcs1.digex.net for mcox@access.digex.com)
  5. Received: by svcs1.digex.net id AA13092
  6.   (5.65c/IDA-1.4.4 for amos-list-out); Wed, 1 Sep 1993 20:27:12 -0400
  7. Received: from access.digex.net by svcs1.digex.net with SMTP id AA13088
  8.   (5.65c/IDA-1.4.4 for <amos-list@svcs1.digex.net>); Wed, 1 Sep 1993 20:27:10 -0400
  9. Received: from bunyip.cc.uq.oz.au by access.digex.net with SMTP id AA14394
  10.   (5.65c/IDA-1.4.4 for <amos-list@access.digex.com>); Wed, 1 Sep 1993 20:27:03 -0400
  11. Received: from elms.concept.com.au (actually 192.132.41.250) 
  12.           by bunyip.cc.uq.oz.au with SMTP (PP); Thu, 2 Sep 1993 10:26:00 +1000
  13. Received: by elms.concept.com.au (4.1/SMI-4.1) id AA28973;
  14.           Thu, 2 Sep 93 10:24:50 EST
  15. Date: Thu, 2 Sep 93 10:24:50 EST
  16. From: Tom Plackowski <tom@elms.concept.com.au>
  17. Message-Id: <9309020024.AA28973@elms.concept.com.au>
  18. To: 95ACHURCH@vax.mbhs.edu
  19. Subject: Re: Jumping/flicker
  20. Cc: amos-list@access.digex.net
  21. Status: RO
  22.  
  23. >Subject: Re: Jumping/flicker
  24.  
  25. >>>If you're using Screen Offset to scroll, you have to remember that it will
  26. >>>move the screen the MOMENT it's called.
  27. >>>Try autoview off and do a view somewhere around the screen swap.
  28. >  Or have XOFS and YOFS variables, and a _WAIT_VBL procedure that does the
  29. >Screen Offset right after the Wait Vbl.  This is similar to what I do in a C
  30. >program I have that needs to scroll a screen around, except I use the Vbl
  31. >interrupt.  I still get a bit of flicker, but little enough that I don't
  32. >worry abot it.
  33.  
  34. What is an XOFS or a YOFS?
  35.  
  36. Theoretically, to move a screen around, I should be able to double buffer - and
  37. update the nondisplayed screen at my convenience. At or during VBL I should be
  38. able to swap screens (presumably just change a pointer somewhere) VERY QUICKLY.
  39.  
  40. I would be supprised to get ANY flicker - perhaps it would indicate that I am
  41. trying to do too much or too many things after the start of VBL.
  42.  
  43. Do you NEED to Screen Offset just after Wait Vbl only because you are not
  44. double buffering?
  45.  
  46.  
  47. >>The scrolling is done using Scroll.
  48. >  This can get ugly in a single-buffered screen, because a Scroll is
  49. >basically a Screen Copy.  You could get part of the old picture and part of
  50. >the new one displayed.
  51.  
  52. Ok, I'll keep that in mind.
  53. The scrolled areas are the width of the screen (320?) but not very tall.
  54.  
  55.  
  56. >>I didn't realise that the Double Buffer had to appear after the Open Screen.
  57. >  That does help.  :-)
  58.  
  59. <fx: sheepish>
  60. It did make a difference 8-).
  61.  
  62.  
  63. >>Why does the manual always say
  64. >>        Screen Swap
  65. >>        Wait Vbl
  66. >>in that order?
  67. >>
  68. >>Does Screen Swap do nothing until VBL? Or will this cause possible flicker on
  69. >>the lower half of the screen?
  70. >Seumas said:
  71. >> ...
  72. >  Screen Swap switches the bitplane pointers in the Screen Base structure with
  73. >the bitplanes that aren't currently displayed, and updates the copper list.
  74. >However, the new bitmap is not displayed until after the vertical blanking
  75. >period, as messing with an active copper list can result in some impressive
  76. >fireworks displays.  So if you do two Screen Swap commands before a vertical
  77. >blank, you'll wind up with the original display staying there.
  78.  
  79. >  It doesn't really matter whether you do Wait Vbl or Screen Swap first, as
  80. >long as you have them both (or you have some other way to make sure you only
  81. >do one Screen Swap per Vbl).
  82.  
  83. Ok! This is useful information!
  84. So screen swap really means, "Swap Screen AT next VBL". (Or is that DURING, or
  85. AFTER?)
  86.  
  87. In fact, it sounds CRUCIAL to have the Screen Swap BEFORE the Wait Vbl.
  88.  
  89.  
  90. You might like to fill me in on the low level mechanism of the graphics/copper
  91. stuff.
  92.  
  93. Correct this please:
  94.     1) Screen Swap adjusts pointers in Screen Base
  95.     1a) New copper list is created? Old one modified?
  96.     2) Video stuff is already committed to display the frame from the
  97.        original pointers, and continues to do so
  98.     3) At VBL the different set of copper instructions directs display to
  99.        come from the new bitplanes
  100. ?
  101.  
  102.  
  103. And anyhow: How do you know these things? Have you looked at the AMOS source?
  104. Is this just conjecture as to how it should be done? How you would do it? The
  105. only way possible?
  106. <fx: no offence! Just checking your credentials!>
  107.  
  108.  
  109. >  --Andy Church
  110.  
  111. Thanks Andy!
  112.  
  113. // Tom